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REMARKS 

This Amendment is submitted in response to the Office Action dated March 14, 2005, 
having a shortened statutory period set to expire June 14, 2005. Claims 21-40 are pendiog. 

Applicants had an ^pointment for a teleconference with the Examiner on May 5, 2005, 
Unfortunately, the Exanuner had to cancel the appointment. Applicants have been xmable to 
reschedule the teleconference before the expiration of the 2-month date jfrom the Office Action. 
Nonetheless, Applicants' legal representative stiU request a telephone call firom the Examiner to 
discuss the pending claims and the offered arguments. 

REJECTIONS UNDER 35 U>S.C. S 103 

In the pxesepat Office Action, Claims 21-40 are rejected under 35 U.S.C, § 103(a) as being 
■unpatentable over Brouckmaja et al. (U.S. Patent No. 6,134,307 — ''Brouckman'*) in view of 
Gallagher et al. (U.S. Patent No. 5,907,603 - "Gallagher'^). 

Brouckman teaches a method for classifying and storing call records in a global 
telecommunications network. The call records (Call Detail Records - CDR) are reviewed to 
ensure that they "are vaUd and comply with industry standards. It then translates this input into 
an industry standard format called Data Message Handling (DMH)" (Brouckman col. 5, lines 12- 
15). The call events classify the incoming call records as either 1) a valid record (no errors in 
key fields); 2) an original CDR record; 3) an invalid record that cannot be further processed; or 
4) an event record containing information needed for billing (Brouckman col, 8, lines 52-65). 

Gallagher teaches a method for extracting fields from a first data stnicture and inserting 
them into predetennined locations in a second data structure (Gallagher coL 4, lines 14-20), such 
that the predetenxiined location is detemnned by the type of record in the field (Gallagher col. 4, 
lines 31-33). Specifically, placement in the second data structure is according to a Field 
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Definition Table (FDT) {Gallagher col 5, lines 3-4). The format for the field ixx both the first 
and second data structure are defined m a Field Translation Table (Gallagher col. 5, lines 18-23), 

With reference to exemplary Claim 21, the cited prior neither teaches nor suggests; 

receiving call data at a local network firom a foreign teleconxmunications network, 
wherein the call data is from a source file having multiple source fields created in the foreign 
telecommunications network (See Figure 5 of the present specification), and wherein the call 
data is for a call made by a user who is registered with the local telecommimicatiotis network but 
who made the call using the foreign telecommunications network (See page 5, lines 11-13 of the 
present specification); 

validating the received call data by confirming that each source field in the received call 
data complies with a first user-defined format (See page 8, lines 5-8 of the present specification); 
and 

in response to validating the received call data, selectively converting the received call 
data into a target file having multiple target fields using a second user-defined fonnat that is 
specific for the local telecommunications network, wherein each target field conforms to the 
second user-defined format (See page 9, lines 7-15 of the present specification). 

Regarding the feature of "validating the received call data by confirming that each source 
field in the received call data complies with a first user-defined format," Brouckman teaches only 
the step of ensuring that call detail records are "valid and comply with an mdustry standards*' 
{Brouckman col. 5, line 13), There is no suggestion that the call detail records "comply with'* a 
particular fonnat. Even if this iuterpretation of the temas *Vahd and comply" were deemed to 
mean "complying with a particular format," there is no teaching or suggestion of using a '"user- 
defined format" by which the data is judged- Gallagher does not mention validating incoming 
data at all. 

Regarding the feature of "selectively converting the received call data into a target file 

having multiple target fields using a second user-defined format that is specific for the local 

teleconomunications network, wherein each target field conforms to the second user-defined 
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foimal;" Brouclanan teaches translating local data into "an indxistry standard format called Data 
Message Handling (DMH)" (Brouckman col. 5, lines 13-15). Note that DMH files are used only 
for processing billing records {Broucknian col. 4, lines 65-66; col 9, lines 48^9). (See pending 
Claim 28.) Gallagher performs no data translation/conversion. 

Note that while Brouckman 's Call Data Record (CDR) may work better if the CDR is in a 
known format (see Brouckman coL 5, lines 11-14), there is no validation of the received call 
data. Similarly, there is no suggestion of "selectively converting the received call data into a 
target file" being performed "in response to validating the received call data " 

With reference to exemplary Claim 22, the cited prior art does not teach or suggest 
'Validating the received call data by using the received call data as an input for a software 
program, wherein the received call data is vaUdated only if the software program produces a 
validating result" (See page 8, lines 11-12 of the present specification). While Gallagher does 
reference a "data conversion routine" for a source structure {Gallagher col, 5, lines 18-23), there 
is no teaching or suggestion that this '"routine" is used to validate the source structure. Neither is 
there any teaching or suggestion of using "the validating result" to populate a target field in the 
target file. (See exemplary pending Claim 23.) 

^ With reference to exemplary Claim 24, the cited prior art does not teach or suggest 
"wherein the second user-defined format is a sum of two or more of the source fields in the 
source file for the received call data." (See page 9, line 1 1 of the present specification.) 

With reference to exemplary Claim 25, the cited prior art does not teach or suggest 
'"wherein the second user-defined format for a field in the target file is a default value that is 
independent of a coTresponding source field in the source file for the received call data." (See 
page 9, line 12 of the present specification.) 

With reference to exemplary Claim 26, the cited prior art does not teach or suggest 
"wherein the first user-defined format has multiple vahdation rules, and wherein each of the 
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multiple validation rules are sequentially applied to the call data, and wherein each of the source 
fields in the source file for the call data is validated only that source field compUes with every 
applicable validation rule jfrom the multiple validation rules." (See page 10, lines 5-8 of the 
present specification.) Rather, Gallagher teaches that each field can have only one type 
definition (Gallagher coL 4, lines 31-33). 

With reference to exemplary Claim 27, the cited prior art does not teach or suggest 
"outputting an error message to the foreign telecommunications network if a source field in the 
source file fails a validation test." (See page 10, lines 19-20 of the present specification-) 

With reference to exemplary Claim 28, the cited prior art does not teach or suggest 
'Svherein the target file is used exclusively for non-billing operations." (See, for example^ the 
^Tfear/Month/Day"' format described on page 8, line 10 of the present specification.) Rather, 
Brouckman teaches that the converted target files are used only for processing biUiixg records 
(Broucfanan col. 4, lines 65-66; col. 9, lines 48-49). 
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CONCLUSION 

Applicants now respectfully request a Notice of Allowance for all pending claijias. 

No extension of time for this response is believed to be necessary. However, in the event 
an extension of titne is required, that extension of time is hereby requested. Please charge any 
fee associated with an extension of time as well as any other fee necessary to further the 
prosecution of this application to IBM CORPORATION DEPOSIT ACCOUNT No. 09-0457. 



Respectfully submitted, 




James Boice 

Registration No. 44,545 

DILLON & YUDELL LLP 

8911 North Capital of Texas Highway 

Suite 2110 

Austin, Texas 78759 

512.343.6116 

ATTORNEY FOR APPLICANT(S) 
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